Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[2.2] Support for receiving commands to manipulate Rollouts #4040

Merged
merged 22 commits into from
Feb 3, 2022

Conversation

douglascamata
Copy link
Contributor

@douglascamata douglascamata commented Jan 24, 2022

Description

This pull requests add support Rollouts manipulation commands sent by Ambassador's backend through Agent directives and reports back with results of their execution.

Currently 3 commands are supported:

  • Pause a rollout.
  • Resume rollout.
  • Abort rollout.

The report includes:

  • The command ID
  • Whether it executed successfully or not
  • A message (error message in case it didn't execute successfully)

Related Issues

List related issues.

Testing

  • Automated tests were added to the rollout command execution logic
  • Manual integration tests were done using a stub of Ambassador's cloud to ensure the commands will be executed as expected and their results correctly reported.

Checklist

  • I made sure to update CHANGELOG.md.

    Remember, the CHANGELOG needs to mention:

    • Any new features
    • Any changes to our included version of Envoy
    • Any non-backward-compatible changes
    • Any deprecations
  • This is unlikely to impact how Ambassador performs at scale.

    Remember, things that might have an impact at scale include:

    • Any significant changes in memory use that might require adjusting the memory limits
    • Any significant changes in CPU use that might require adjusting the CPU limits
    • Anything that might change how many replicas users should use
    • Changes that impact data-plane latency/scalability
  • My change is adequately tested.

    Remember when considering testing:

    • Your change needs to be specifically covered by tests.
      • Tests need to cover all the states where your change is relevant: for example, if you add a behavior that can be enabled or disabled, you'll need tests that cover the enabled case and tests that cover the disabled case. It's not sufficient just to test with the behavior enabled.
    • You also need to make sure that the entire area being changed has adequate test coverage.
      • If existing tests don't actually cover the entire area being changed, add tests.
      • This applies even for aspects of the area that you're not changing – check the test coverage, and improve it if needed!
    • We should lean on the bulk of code being covered by unit tests, but...
    • ... an end-to-end test should cover the integration points
  • I updated DEVELOPING.md with any any special dev tricks I had to use to work on this code efficiently.

@douglascamata douglascamata self-assigned this Jan 25, 2022
@douglascamata douglascamata added the t:feature New feature or enhancement request label Jan 25, 2022
@douglascamata douglascamata marked this pull request as ready for review January 25, 2022 10:50
@douglascamata douglascamata requested a review from kflynn January 25, 2022 10:50
@douglascamata douglascamata force-pushed the dcamata/remote-control-rollouts branch from cfae4fc to f7911b9 Compare January 31, 2022 18:30
douglascamata and others added 14 commits January 31, 2022 12:50
Signed-off-by: Douglas Camata <[email protected]>
Signed-off-by: Luke Shumaker <[email protected]>
Signed-off-by: Douglas Camata <[email protected]>
Signed-off-by: Luke Shumaker <[email protected]>
Signed-off-by: Douglas Camata <[email protected]>
Signed-off-by: Luke Shumaker <[email protected]>
Signed-off-by: Douglas Camata <[email protected]>
Signed-off-by: Luke Shumaker <[email protected]>
Signed-off-by: Douglas Camata <[email protected]>
Signed-off-by: Luke Shumaker <[email protected]>
Signed-off-by: Douglas Camata <[email protected]>
Signed-off-by: Luke Shumaker <[email protected]>
Signed-off-by: Douglas Camata <[email protected]>
Signed-off-by: Luke Shumaker <[email protected]>
Signed-off-by: Douglas Camata <[email protected]>
Signed-off-by: Luke Shumaker <[email protected]>
Signed-off-by: Douglas Camata <[email protected]>
Signed-off-by: Luke Shumaker <[email protected]>
Signed-off-by: Douglas Camata <[email protected]>
Signed-off-by: Luke Shumaker <[email protected]>
Signed-off-by: Douglas Camata <[email protected]>
Signed-off-by: Luke Shumaker <[email protected]>
Signed-off-by: Douglas Camata <[email protected]>
Signed-off-by: Luke Shumaker <[email protected]>
@LukeShu LukeShu force-pushed the dcamata/remote-control-rollouts branch from f7911b9 to a64e90d Compare January 31, 2022 20:22
@LukeShu LukeShu changed the base branch from master to lukeshu/upgrade-client-go January 31, 2022 20:22
@LukeShu
Copy link
Contributor

LukeShu commented Jan 31, 2022

I've rebased this on to lukeshu/upgrade-client-go and squashed a few commits that should have been squashed. The diff from a naive git merge origin/lukeshu/upgrade-client-go (which I pushed as lukeshu/merge/dcamata/remote-control-rollouts, if you want to see it) is as follows:

diff --git a/builder/Dockerfile b/builder/Dockerfile
index da85aba1a..279e6fc94 100644
--- a/builder/Dockerfile
+++ b/builder/Dockerfile
@@ -79,6 +79,7 @@ ADD pkg pkg
 ADD vendor vendor
 ADD go.mod go.mod
 ADD go.sum go.sum
+
 RUN --mount=type=cache,target=/root/.cache/go-build \
     mkdir -p /go/bin && \
 	time go build -mod=vendor -o /go/bin/ ./cmd/...
diff --git a/go.mod b/go.mod
index cb8d5f737..03fb51bcc 100644
--- a/go.mod
+++ b/go.mod
@@ -48,6 +48,7 @@ go 1.17
 require (
 	github.com/Masterminds/semver v1.5.0 // indirect
 	github.com/Masterminds/sprig v2.22.0+incompatible
+	github.com/argoproj/argo-rollouts v1.0.7
 	github.com/asaskevich/govalidator v0.0.0-20200428143746-21a406dcc535 // indirect
 	github.com/census-instrumentation/opencensus-proto v0.2.1
 	github.com/cncf/udpa/go v0.0.0-20210322005330-6414d713912e
@@ -98,8 +99,6 @@ require (
 	sigs.k8s.io/yaml v1.2.0
 )
 
-require github.com/argoproj/argo-rollouts v1.0.7
-
 require (
 	cloud.google.com/go v0.58.0 // indirect
 	github.com/Azure/go-ansiterm v0.0.0-20170929234023-d6e3b3328b78 // indirect

Base automatically changed from lukeshu/upgrade-client-go to master February 1, 2022 04:34
@khussey khussey changed the title Support for receiving commands to manipulate Rollouts [2.2] Support for receiving commands to manipulate Rollouts Feb 2, 2022
rp4rk
rp4rk previously approved these changes Feb 2, 2022
Copy link

@rp4rk rp4rk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Douglas Camata added 2 commits February 2, 2022 16:44
kflynn
kflynn previously approved these changes Feb 3, 2022
Copy link
Member

@kflynn kflynn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to handle merge conflicts and tests, but this looks good! 🙂 My comments below are things that don't need to block landing this.

)

// rolloutsGetterFactory is a factory for creating RolloutsGetter.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So what's the purpose of a RolloutsGetter?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The purpose of RolloutsGetter is to fetch Rollouts in a namespace inside the cluster.

- title: Support received commands to pause, continue and abort a Rollout via Agent directives
type: feature
body: >-
The Emissary agent now receive commands to manipulate Rollouts (pause, continue, and abort are
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should really be "receives". 🙂

Comment on lines +102 to +104
a.ambassadorAPIKeyMutex.Lock()
apiKey := a.ambassadorAPIKey
a.ambassadorAPIKeyMutex.Unlock()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be worth a comment that you really don't want to hold this lock during the report-command-result call.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kflynn Why? Where would you recommend to use the mutex to access the api key from the agent and send it down to this point?

@LukeShu LukeShu self-requested a review February 3, 2022 18:25
LukeShu
LukeShu previously approved these changes Feb 3, 2022
Copy link
Contributor

@LukeShu LukeShu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolve the conflicts, and it looks fine to me.

Douglas Camata added 2 commits February 3, 2022 20:11
@douglascamata douglascamata dismissed stale reviews from LukeShu and kflynn via 9c07c67 February 3, 2022 19:17
Signed-off-by: Douglas Camata <[email protected]>
@LukeShu LukeShu self-requested a review February 3, 2022 21:15
@LukeShu LukeShu merged commit 7023e92 into master Feb 3, 2022
@LukeShu LukeShu deleted the dcamata/remote-control-rollouts branch February 3, 2022 21:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
t:feature New feature or enhancement request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants